home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / answers / comp / ripem / attacks < prev    next >
Text File  |  1994-01-18  |  11KB  |  213 lines
  1. Newsgroups: alt.security.ripem,sci.crypt,comp.security.misc,alt.security,comp.mail.misc,ac.c.690.crypt,alt.answers,comp.answers,news.answers
  2. Path: bloom-beacon.mit.edu!nic.hookup.net!swrinde!cs.utexas.edu!math.ohio-state.edu!sol.ctr.columbia.edu!usenet.ucs.indiana.edu!silver.ucs.indiana.edu!mvanheyn
  3. From: Marc VanHeyningen <mvanheyn@cs.indiana.edu>
  4. Subject: RIPEM Frequently Noted Vulnerabilities
  5. Content-Type: text/x-usenet-FAQ; version=1.0; title="RIPEM Attacks"
  6. Message-ID: <CJsnsC.Hzu@usenet.ucs.indiana.edu>
  7. Followup-To: alt.security.ripem
  8. Originator: mvanheyn@silver.ucs.indiana.edu
  9. Sender: news@usenet.ucs.indiana.edu (USENET News System)
  10. Nntp-Posting-Host: silver.ucs.indiana.edu
  11. Organization: Computer Science, Indiana University
  12. Mime-Version: 1.0
  13. Date: Mon, 17 Jan 1994 22:00:11 GMT
  14. Approved: news-answers-request@MIT.EDU
  15. Expires: Wed, 20 Apr 1994 00:00:00 GMT
  16. Lines: 194
  17. Xref: bloom-beacon.mit.edu alt.security.ripem:431 sci.crypt:13557 comp.security.misc:6131 alt.security:6246 comp.mail.misc:5922 alt.answers:1655 comp.answers:3461 news.answers:14228
  18.  
  19. Archive-name: ripem/attacks
  20. Last-update: 10 Nov 93 21:00:00 -0500
  21.  
  22. SOME POSSIBLE ATTACKS ON RIPEM
  23. ------------------------------
  24.  
  25. This is a living list of potential weaknesses to keep your eyes open
  26. for when using RIPEM for secure electronic mail.  It does not go into
  27. great detail, and is almost certainly not exhaustive.  Obviously, many
  28. of the weaknesses are weaknesses of cryptographically secured mail in
  29. general, and will pertain to secure mail programs other than RIPEM.
  30. It is maintained by Marc VanHeyningen <mvanheyn@cs.indiana.edu>.  It
  31. is posted monthly to a variety of news groups; followups pertaining
  32. specifically to RIPEM should go to alt.security.ripem.
  33.  
  34. CRYPTANALYSIS ATTACKS
  35. ---------------------
  36.  
  37. - Breaking RSA would allow an attacker to find out your private key,
  38.   in which case he could read any mail encrypted to you and sign
  39.   messages with your private key.
  40.  
  41.   RSA is generally believed to be resistant to all standard
  42.   cryptanalytic techniques.  Even a standard key (about 516 bits with
  43.   RIPEM) is long enough to render this impractical, barring a
  44.   huge investment in hardware or a breakthrough in factoring.
  45.  
  46. - Breaking DES would allow an attacker to read any given message,
  47.   since the message itself is encrypted with DES.  It would not allow
  48.   an attacker to claim to be you.
  49.  
  50.   DES has only 56 bits in its key, and thus could conceivably be
  51.   compromised by brute force with sufficient hardware, but few agencies
  52.   have such money to devote to simply read a message.  Since each
  53.   message has a different DES key, the work for each message would
  54.   remain significant.  RIPEM 1.1 allows triple-DES to be used as an
  55.   option; it is believed stronger than single-DES and should resist
  56.   brute force attacks.
  57.  
  58. KEY MANAGEMENT ATTACKS
  59. ----------------------
  60.  
  61. - Stealing your private key would allow the same benefits as breaking
  62.   RSA.  To safeguard it, it is encrypted with a DES key which is derived
  63.   from a passphrase you type in.  However, if an attacker can get a copy
  64.   of your private keyfile and your passphrase (by snooping network
  65.   packets, tapping lines, or whatever) he could break the whole scheme.
  66.  
  67.   The main risk is that of transferring either the passphrase or the
  68.   private key file across an untrusted link.  So don't do that.  Run 
  69.   RIPEM on a trusted machine, preferably one sitting right in front of
  70.   you.  Ideally, your own machine in your own home (or maybe office)
  71.   which nobody else has physical access to.
  72.  
  73. - Fooling you into accepting a bogus public key for someone else could 
  74.   allow an opponent to deceive you into sending secret messages to him
  75.   rather than to the real recipient.  If the enemy can fool your
  76.   intended recipient as well, he could re-encrypt the messages with
  77.   the other bogus public key and pass them along.
  78.  
  79.   It is important to get the proper public keys of other people.
  80.   The most common mechanism for this is finger; assuming the opponent
  81.   has not compromised routers or daemons or such, finger can be 
  82.   given a fair amount of trust.  The strongest method of key
  83.   authentication is to exchange keys in person; however, this is
  84.   not always practical.  Having other people "vouch for you" by
  85.   signing a statement containing your key is possible, although 
  86.   RIPEM doesn't have features for doing this as automatically as
  87.   PGP.  RIPEM does generate and check MD5 fingerprints of public keys
  88.   in the key files; they may be exchanged via a separate channel for
  89.   authentication.
  90.  
  91. PLAYBACK ATTACKS
  92. ----------------
  93.  
  94. - Even if an opponent cannot break the cryptography, an opponent could
  95.   still cause difficulties.  For example, suppose you send a message
  96.   with MIC-ONLY (a PEM mode which does not provide disclosure protection)
  97.   to Alice which says "OK, let's do that." Your opponent intercepts
  98.   it, and now resends it to Bob, who now has a message which is
  99.   authenticated as from you telling him to do that.  Of course, he may
  100.   interpret it in an entirely different context.  Or your opponent
  101.   could transmit the same message to the same recipient much later,
  102.   figuring it would be seen differently at a later time.  Or the
  103.   opponent could change the Originator-Name: to himself, register 
  104.   your public key as his, and send a message hoping the recipient
  105.   will send him return mail indicating (perhaps even quoting!) the
  106.   unknown message.
  107.  
  108.   To defeat playback attacks, the plaintext of each message should 
  109.   include some indication of the sender and recipient, and a unique
  110.   identifier (typically the date).  A good front-end script for RIPEM
  111.   should do this automatically (IMHO).  As a recipient, you should be
  112.   sure that the Originator-Name: header and the sender indicated within
  113.   the plaintext are the same, that you really are a recipient, and that
  114.   the message is not an old one.  Some this also can and should be
  115.   automated.  The author of this FAQ has made a modest attempt at
  116.   automating the process of generating and checking encapsulated
  117.   headers; the programs are included in the standard distribution in
  118.   the utils directory.
  119.  
  120. LOCAL ATTACKS
  121. -------------
  122.  
  123. - Clearly, the security of RIPEM cannot be greater than the security of
  124.   the machine where the encryption is performed.  For example, under
  125.   UNIX, a super-user could manage to get at your encrypted mail,
  126.   although it would take some planning and effort to do something like
  127.   replace the RIPEM executable with a Trojan horse or to get a copy of
  128.   the plaintext, depending how it's stored.
  129.  
  130.   In addition, the link between you and the machine running RIPEM is
  131.   an extension of that.  If you decrypt with RIPEM on a remote machine
  132.   which you are connected to via network (or, worse yet, modem), an
  133.   eavesdropper could see the plaintext (and probably also your
  134.   passphrase.)
  135.  
  136.   RIPEM should only be executed on systems you trust, obviously.  In
  137.   the extreme case, RIPEM should only be used on your own machine,
  138.   which you have total control over and which nobody else has access
  139.   to, which has only carefully examined software known to be free of
  140.   viruses, and so on.  However, there's a very real trade-off between
  141.   convenience and security here.
  142.  
  143.   A more moderately cautious user might use RIPEM on a UNIX workstation
  144.   where other people have access (even root access), but increase
  145.   security by keeping private keys and the (statically linked, of
  146.   course) executable on a floppy disk.
  147.  
  148.   Some people will keep RIPEM on a multi-user system, but when dialing
  149.   in over an insecure line, they will download the message to their
  150.   own system and perform the RIPEM decryption there.  However, the
  151.   security provided by such a mechanism is somewhat illusory; since
  152.   you presumably type your cleartext password to log in, you've just
  153.   given away the store, since the attacker can now log in as you and
  154.   install traps in your account to steal your private key next time
  155.   you use it from a less insecure line.  This will likely remain the
  156.   situation as long as most systems use the rather quaint mechanism of
  157.   cleartext password authentication.
  158.  
  159.   I find it nice to put a brief statement of how carefully I manage my
  160.   security arrangement in my .plan next to my public key, so that
  161.   potential correspondents can be aware what level of precautions are
  162.   in place.  Some people use two keys, a short one which is not
  163.   carefully managed for ordinary use and a longer one which is treated
  164.   with greater care for critical correspondence.
  165.  
  166. UNTRUSTED PARTNER ATTACKS
  167. -------------------------
  168.  
  169. - RIPEM's encryption will ensure that only a person with the private key
  170.   corresponding to the public key used to encrypt the data may read the
  171.   traffic.  However, once someone with that key gets the message, she
  172.   may always make whatever kind of transformations she wishes.  There 
  173.   exist no cryptographic barriers to a recipient, say, taking an
  174.   ENCRYPTED message and converting it to a MIC-ONLY message, signed by
  175.   you and readable by anyone, although RIPEM does not provide this
  176.   functionality.  Indeed, the latest PEM draft I have seen specifically
  177.   states that such transformations should be possible to allow
  178.   forwarding functions to work.
  179.  
  180.   Including the recipients in the plaintext, as mentioned above, will
  181.   make it possible for recipients of a redistributed message to be aware
  182.   of its original nature.  Naturally, the security of the cryptography
  183.   can never be greater than the security of the people using it.
  184.  
  185. TRAFFIC ANALYSIS ATTACKS
  186. ------------------------
  187.  
  188. - Some attacks are outside the scope of the PEM standard; traffic
  189.   analysis is a prominent one of these.     PEM does not prevent an enemy
  190.   from potentially discovering who your traffic is being exchanged
  191.   with and how often/lengthy these messages are.  This can be a
  192.   problem for some people, though the potential for invasion of
  193.   privacy may be more a collective than an individual one.  An
  194.   interesting paper on a potential application of traffic analysis is
  195.   mentioned below.
  196.  
  197.   The traditional way to prevent traffic analysis is to throw a lot of
  198.   bogus traffic into the channel to obscure the real stuff; this could
  199.   be done but would be rather detrimental to network load and bogus
  200.   message recipients.  Trusted third-party re-mailers that handle
  201.   aliases can help some, though aliases that are frequently used can
  202.   still be analyzed (indeed, traffic analysis might determine which
  203.   aliases go with which real people.)
  204.  
  205.   Interesting reference:
  206.   Schwartz and Wood.  ``Discovering shared interests using graph
  207.   analysis.''  CACM, August 1993.
  208.   
  209.   Plain text version is in:
  210.     ftp.cs.colorado.edu:/pub/cs/techreports/schwartz/ASCII/Email.Study.txt.Z
  211.   Postscript version is in:
  212.     ftp.cs.colorado.edu:/pub/cs/techreports/schwartz/PostScript/Email.Study
  213.